前兩天把專案交給 Codex 之後，我一直在想一個問題，如果只是叫 AI 改一個 function、修一個明確的 bug，其實跟以前把程式碼貼進 ChatGPT 沒有差得那麼多，真正讓 Coding Agent 不一樣的地方，應該是它可以自己在 repository 裡找東西。
所以今天我沒有直接告訴它要改哪個檔案，也沒有把相關程式碼整理好再貼給它，而是故意把問題講得比較接近平常真的會遇到的狀況：只描述我看到的現象，然後讓它自己去找問題在哪裡。
這件事看起來只是少講幾個檔名，但其實差很多，因為以前使用 AI 寫程式時，我才是那個真正理解專案的人，AI 只負責處理我切出來的一小塊；現在如果把整個 repository 交出去，它就得自己回答另一個更麻煩的問題——這個功能到底是怎麼一路跑起來的？
平常 debug 的時候，我們很容易直接把懷疑的檔案丟給 AI，例如覺得 API 有問題，就貼 API handler；覺得資料格式有問題，就貼 schema，這樣當然很方便，但也等於偷偷幫 AI 做完一半的工作。
今天我反過來，只告訴 Codex「哪個功能的行為跟預期不一樣」，接著看它會先讀什麼。
它沒有馬上開始修改程式，而是先搜尋 repository 裡跟這個功能有關的名稱，再沿著 import、function call 和資料結構往其他檔案找，過程中會碰到入口、處理邏輯、設定檔，甚至一些我一開始根本沒有想到會有關係的地方。
這時候我才比較明顯感覺到 Coding Agent 跟一般聊天式 AI 的差異，不只是它可以一次看到比較多程式碼，而是它真的可以自己決定「下一個要去哪裡找」。
小型練習很容易讓人產生錯覺，好像一個 bug 就對應一個 function、一個 function 就對應一個檔案，但真的專案通常不是這樣。
前端送出一筆資料，可能先經過 API，再進 service，接著碰到 schema、database 或其他 module，中間只要有一層理解錯，最後看到的問題可能完全出現在另一個地方。
以前我把程式碼貼給 AI 時，其實已經先把這條路走過一次了，我知道哪些檔案有關，所以才知道要貼什麼；但今天沒有先幫 Codex 做這件事，它必須自己從現象反推路徑。
我覺得這才是今天真正值得測的地方，因為「會寫一段正確的程式碼」跟「知道應該改哪一段程式碼」，其實是兩種不同能力。
不過看到 Codex 可以自己搜尋之後，我也沒有直接讓它修改。
原因很簡單，搜尋到正確檔案只代表第一關過了，接下來還要看它對這些檔案之間的關係理解得對不對，所以我先要求它解釋目前看到的流程，包括功能從哪裡進來、資料經過哪些地方、中間有哪些轉換，以及它認為問題最可能出在哪一層。
這一步意外地很好用。
因為如果直接叫 Agent 修，它最後可能真的改出一個「看起來能跑」的版本，但我很難知道它是理解架構之後才改，還是剛好在某個地方補了一個判斷把症狀蓋掉。
先叫它說明，反而可以在真正動程式之前發現它有沒有走錯方向。
做到這裡，我突然覺得測 Coding Agent 最適合的方式，可能不是一直問「它寫的程式碼有沒有比我好」，而是把它當成一個剛加入專案的人。
如果今天有一個新組員加入，我大概也不會丟一個檔案給他說「幫我改第 73 行」，比較可能是告訴他目前哪個功能有問題，讓他先把相關程式看過，再跟我說他認為問題在哪。
差別只是人類可能會跑來問我「這個檔案是做什麼的」，Codex 則會先自己搜尋。
這也讓我重新理解所謂的「Agent」，重點可能不只是模型會不會寫 Code，而是它能不能自己完成中間那些原本都要由工程師處理的步驟：找檔案、讀架構、追資料流、提出假設，最後才進到修改。
今天的結果比我原本預期好，但也讓另一個問題變得更明顯。
當專案越來越大，Agent 一次讀到的東西越多，我反而更難確認它是不是漏掉了某個重要條件，例如它可能理解主要流程，卻沒注意到測試、環境變數、舊版相容邏輯，甚至某個只有特殊情況才會走到的 branch。
所以現在我的做法不會是「Codex 看完整個 repo → 直接接受修改」，而比較像：
先讓它找 → 讓它解釋 → 看它準備改哪裡 → 再讓它動手。
至少目前這樣用，我會比一句「幫我修這個 bug」放心很多。
Day 1 我測的是 Codex 能不能自己讀一個陌生專案，Day 2 開始把真的 Bug 交給它，到了 Day 3，我比較確定自己真正想測的是什麼了。
如果 Coding Agent 最後只能幫我把程式碼寫快一點，那它比較像是一個更方便的程式碼生成工具；但如果它能自己從問題找到相關檔案、理解跨檔案的關係，再決定應該從哪裡下手，那才開始接近我原本想像中的「軟體工程 Agent」。
明天我想再往前一步，不只看它會不會改，而是看它改完之後，到底知不知道自己有沒有把東西改壞。
iThome鐵人賽
看影片追技術